Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-013

Text File | 1995-12-31 | 83KB | 2,265 lines

Received-Date: Wed, 13 Apr 1994 14:54:36 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-013
To: [e-mail]
Date: Wed, 13 Apr 94 14:54:30 MET DST
X-Mailer: ELM [version 2.3 PL11]
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 15

C.S.M.P. Digest             Wed, 13 Apr 94       Volume 3 : Issue 13

Today's Topics:

        AppleEvents to Run Excel?
        Finding the High Bit
        Generating Activate Events
        I got my PPC PDS card...
        Moving an editText area in a Modal Dialog Q
        PPC Development and MPW Tools
        PowerMac Programming
        PowerMacs and ARTA
        Quickdraw GX Beta 3



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From [e-mail] (Dale M. Greer)
Subject: AppleEvents to Run Excel?
Date: 28 Mar 1994 20:56:10 GMT
Organization: The University of Texas at Dallas

I need to make an application to run Excel from a C program.  I've
got the MS Excel SDK and the IM IAC books.  The former describes
objects and event which act upon them, while the latter gives
examples of how to use AppleEvents.  But these examples aren't
much use helping me figure out how to do it with Excel, and the
Excel book has no examples at all.  Can someone point me in the
right direction as to how to find how how to do what I need to do?

My code will get data from somewhere, and then create a .XLS file
from the data.  To do the latter, the code will use AppleEvents to
run Excel to create a spreadsheet and enter the data there.

--

Dale Greer, [e-mail]
"You can't just wake up and kiss the mirror and say 'I'm so purdy,
 I think I'll run for Governor.'" - Texas Gov. Ann Richards



+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Tue, 29 Mar 1994 10:16:36 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Dale M. Greer ([e-mail]) wrote:
> I need to make an application to run Excel from a C program.  I've
> got the MS Excel SDK and the IM IAC books.  The former describes
> objects and event which act upon them, while the latter gives
> examples of how to use AppleEvents.  But these examples aren't
> much use helping me figure out how to do it with Excel, and the
> Excel book has no examples at all.  Can someone point me in the
> right direction as to how to find how how to do what I need to do?

Let me just say that I know all about this stuff and I wouldn't take on
that job for all the tea in China!

Of course, if I WERE stupid enough, I would simply implement the OSALoad &
OSAExecute calls in my program so that I could run scripts and do all the
Excel crap (and that's the part I wouldn't touch) in scripts.  That would
save you lots of time.  Once you got it working (or should I say IF) you
could save the script readonly for distribution as a program resource.

Excel is one of the worst scriptable apps in existence and very poorly
documented, if you can even call it documentation.  Hopefully someone
will take pity on you and provide example scripts.  You'll need them.

You'll need AppleScript for this too.  It's the OSA layer.

Jon

+++++++++++++++++++++++++++

>From [e-mail] (Dale M. Greer)
Date: 29 Mar 1994 14:45:43 GMT
Organization: The University of Texas at Dallas

Jon Pugh ([e-mail]) wrote:
> Dale M. Greer ([e-mail]) wrote:
> > I need to make an application to run Excel from a C program.  I've
> > got the MS Excel SDK and the IM IAC books.  The former describes
> > objects and event which act upon them, while the latter gives
> > examples of how to use AppleEvents.  But these examples aren't
> > much use helping me figure out how to do it with Excel, and the
> > Excel book has no examples at all.  Can someone point me in the
> > right direction as to how to find how how to do what I need to do?

> Let me just say that I know all about this stuff and I wouldn't take on
> that job for all the tea in China!

> Of course, if I WERE stupid enough, I would simply implement the OSALoad &
> OSAExecute calls in my program so that I could run scripts and do all the
> Excel crap (and that's the part I wouldn't touch) in scripts.  That would
> save you lots of time.  Once you got it working (or should I say IF) you
> could save the script readonly for distribution as a program resource.

> Excel is one of the worst scriptable apps in existence and very poorly
> documented, if you can even call it documentation.  Hopefully someone
> will take pity on you and provide example scripts.  You'll need them.

> You'll need AppleScript for this too.  It's the OSA layer.

Thanks for the encouraging words!  ;-)

I was considering the tack you suggest, and was able to load and manipulate
data into a spreadsheet from an AppleScript script.  But it just seems
kind of ugly to have software components strewn all over the disk.  On
the other hand, we've only got about 4 weeks to do this, so I might
just do the quick and dirty first, and tidy it up later.

At least there is an example of how to load, compile and execute a
script in the IM IAC book.  And I actually found an example of how to
use Create Element, but in the Recording Apple Events section instead
of the Creating and Sending Apple Events section where one might have
hoped it would be.  Still no success there, but I think I'm converging
on it.

--

Dale Greer, [e-mail]
"You can't just wake up and kiss the mirror and say 'I'm so purdy,
 I think I'll run for Governor.'" - Texas Gov. Ann Richards



+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: Tue, 29 Mar 94 17:14:07 GMT
Organization: National Renewable Energy Laboratory

In article <[e-mail]> Jon Pugh, [e-mail]
writes:
>Excel is one of the worst scriptable apps in existence and very poorly
>documented, if you can even call it documentation.  Hopefully someone
>will take pity on you and provide example scripts.  You'll need them.

Ugh -- X-barf.  This reminds me of the time I had to write a external
function to allow a macro to do serial I/O.  The external was easy --
integrating it into and debugging the macro was, shall we say, less than
pleasant.  I was ready for a self-lobotomy about half way through.  Excel
macro language -- absolutely the worst programming environment I have
ever personally been exposed to.

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Tue, 29 Mar 1994 18:40:12 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

[e-mail] (Jon Pugh) writes:
>Dale M. Greer ([e-mail]) wrote:
>> I need to make an application to run Excel from a C program.  I've
>> got the MS Excel SDK and the IM IAC books.  The former describes
>> objects and event which act upon them, while the latter gives
>> examples of how to use AppleEvents.  But these examples aren't
>> much use helping me figure out how to do it with Excel, and the
>> Excel book has no examples at all.  Can someone point me in the
>> right direction as to how to find how how to do what I need to do?

>Let me just say that I know all about this stuff and I wouldn't take on
>that job for all the tea in China!

     I did the other side of this last year.  I had to write a program
that received and processed the Table Suite events that Excel
understands.  It's a pain, and it runs slow, but it can be done.
It doesn't require AppleScript at all.  But I had to write a few thousand
lines of code to do it.

     Here, for reference, is the AppleEvent which sets cell [1,1] to
a value of 0.0:

AppleEvent received:
AppleEvent: Class 'core'  ID 'setd'
  List of 2 items:
  [ 1]  Key: '----'  Type: 'obj '
    Record of 4 items:
    [ 1]  Key: 'want'  Type: 'type'
    [ 1]  4 bytes:
    [ 1]    0x00:  0x6363656c  'ccel'

    [ 2]  Key: 'from'  Type: 'obj '
      Record of 4 items:
      [ 1]  Key: 'want'  Type: 'type'
      [ 1]  4 bytes:
      [ 1]    0x00:  0x63726f77  'crow'

      [ 2]  Key: 'from'  Type: 'obj '
        Record of 4 items:
        [ 1]  Key: 'want'  Type: 'type'
        [ 1]  4 bytes:
        [ 1]    0x00:  0x646f6375  'docu'

        [ 2]  Key: 'from'  Type: 'null'
        [ 2]  0 bytes:

        [ 3]  Key: 'form'  Type: 'enum'
        [ 3]  4 bytes:
        [ 3]    0x00:  0x6e616d65  'name'

        [ 4]  Key: 'seld'  Type: 'TEXT'
        [ 4]  Text (9 chars):
        [ 4]  "Link file"
      [ 3]  Key: 'form'  Type: 'enum'
      [ 3]  4 bytes:
      [ 3]    0x00:  0x696e6478  'indx'

      [ 4]  Key: 'seld'  Type: 'long'
      [ 4]  Text (1 chars):
      [ 4]  "1"
    [ 3]  Key: 'form'  Type: 'enum'
    [ 3]  4 bytes:
    [ 3]    0x00:  0x696e6478  'indx'

    [ 4]  Key: 'seld'  Type: 'long'
    [ 4]  Text (1 chars):
    [ 4]  "1"
  [ 2]  Key: 'data'  Type: 'TEXT'
  [ 2]  Text (5 chars):
  [ 2]  "0.000"


                        John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Tue, 29 Mar 1994 11:22:30 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (Jon Pugh)
wrote:

> Excel is one of the worst scriptable apps in existence and very poorly
> documented, if you can even call it documentation.  Hopefully someone
> will take pity on you and provide example scripts.  You'll need them.

Well, Excel was also one of the earliest scriptable applications, and some
things changed after it came out (like Apple appropriating the word
"text").  Excel even came before the change in Frontier's construction of
object specifiers between Frontier 1.0 (weird, and I never fully "got" it)
and Frontier 2.0 (quite simple), so, unlike the FileMaker folks, the Excel
developers didn't even have Frontier to use for testing.

So while Excel has problems, it at least has a decent excuse.

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

+++++++++++++++++++++++++++

>From Manuel Veloso <[e-mail]>
Date: Wed, 30 Mar 1994 06:41:04 GMT
Organization: Ibex Productions

In article <[e-mail]> Jon Pugh, [e-mail] writes:
>Excel is one of the worst scriptable apps in existence and very poorly
>documented, if you can even call it documentation.  Hopefully someone
>will take pity on you and provide example scripts.  You'll need them.

That's really true. However, on AOL there's some documentation written
by one of the Excel guys about its applescript/ae support, and it works.
I was always under the impression you needed the "R1C1" format,
but Excel actually supports the "row 1 of column 5" specifier.

I really don't quite know where to post this, but if people want it
I can send them a copy.

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Wed, 30 Mar 1994 18:34:42 GMT
Organization: ISIS International

Carl R. Osterwald <[e-mail]> writes:

>In article <[e-mail]> Jon Pugh, [e-mail]
>writes:
>>Excel is one of the worst scriptable apps in existence and very poorly
>>documented, if you can even call it documentation.  Hopefully someone
>>will take pity on you and provide example scripts.  You'll need them.

>Ugh -- X-barf.  This reminds me of the time I had to write a external
>function to allow a macro to do serial I/O.  The external was easy --
>integrating it into and debugging the macro was, shall we say, less than
>pleasant.  I was ready for a self-lobotomy about half way through.  Excel
>macro language -- absolutely the worst programming environment I have
>ever personally been exposed to.

There's one even worse - FoxPro (which I've unfortunately been doing a lot of
work with lately). Is it a coincidence that both are from Microsoft?
--
Mike Cohen - [e-mail]
NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20

+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: Wed, 30 Mar 94 22:58:30 GMT
Organization: National Renewable Energy Laboratory

In article <[e-mail]> Mike Cohen, [e-mail] writes:
>There's one even worse - FoxPro (which I've unfortunately been doing a
lot of
>work with lately).

Well, I hope I don't have to find out!

>Is it a coincidence that both are from Microsoft?

Most likely not.

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 30 Mar 1994 09:41:47 -0800
Organization: Internet for the Olympic Peninsula

As an experiment, I have added a source file to a toy application in which
I am experimenting with OSA issues.

The addition implements two ways to cause Excel to launch (if it isn't
running), open a particular toy spreadsheet (if it isn't open), and set
cell 1 of row 1 of that spreadsheet to a value (ie, set the formula of the
cell to a formula which produces the value).

The two ways:  1--compile and execute an OSA script (I used AppleScript);
2--use toolbox (LaunchApplication), AE Manager, and other routines to
launch Excel and send the appropriate events.

It took around a half hour (half of which was reminding myself of toolbox
details) to get the OSA script method running...in the course of which I
learned a detail about Excel scripting [below].  The rest of the evening
(not full time) got the other method to the point of launching Excel (if
necessary), and opening the document.  Now I need to go back and check
whether the document is open, and set the cell formula.

I expect to post the resulting source code to the server at
gaea.kgs.ukans.edu as sampleware when it's ready.

Go the OSA route:  it's simpler and less painful, provided you know your
execution environment HAS a scripting environment (AppleScript or Frontier)
running.

- --------Excel Note---------
If you send Excel an open event for a spreadsheet which is already open and
modified, Excel demands to come to the front so it can ask the user whether
to revert the document.  Excel does this even if the open event is sent
with the kAENeverInteract flag.

So:  in scripts (or the other way), check for the document being open
first.
--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

---------------------------

>From Chris Russo <[e-mail]>
Subject: Finding the High Bit
Date: 24 Mar 1994 17:58:53 GMT
Organization: Sonic Systems, Inc.

Hi all,

    I need to find the high bit in a long as quickly as possible.
1. I could brute-force shift left till negative.
2. I could brute-force shift right till zero.
3. I could create a 256 byte lookup table and do 1-4 lookups.
4. Someone on the net could show me some neat new algorithm, like
    (number)>>(number>>1) ^ number = solution.  There HAS to be
     something like that out there somewhere. :-)

Thanks in advance,

Chris Russo

Note new address -> [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Thu, 24 Mar 1994 12:28:48 -0600
Organization: University of Illinois at Urbana-Champaign

In article <2mskct$[e-mail]>, Chris Russo
<[e-mail]> wrote:

>        I need to find the high bit in a long as quickly as possible.

If you don't care about doing it in C and you can depend on a 68020 or better:

#pragma parameter __D0 FindFirstOne(__D0)
long FindFirstOne(long value) = {0xEDCO,0x0000};

Otherwise, I think the brute force shift right is best if you put the
value into an unsigned long first:

    myUnsigned = myLong;
    bitCount = 0;
    while(myUnsigned != 0L) {
        ++bitCount;
        myUnsigned >>= 1;
    }

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Gary Kacmarcik)
Date: 25 Mar 1994 16:43:12 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)


In article <2mskct$[e-mail]> Chris Russo <[e-mail]> writes:

>  I need to find the high bit in a long as quickly as possible.
>  1. I could brute-force shift left till negative.
>  2. I could brute-force shift right till zero.
>  3. I could create a 256 byte lookup table and do 1-4 lookups.
>  4. Someone on the net could show me some neat new algorithm, like
>      (number)>>(number>>1) ^ number = solution.  There HAS to be
>      something like that out there somewhere. :-)

well, i'm not sure if this is of value to you, but if you can assume
that you're on a PowerPC-based Mac, you can use the cntlzw (Count
Leading Zeros Word) instruction.

the syntax is:
   cntlzw[.]    rA,rS

and it returns (in rA) the number of leading zeros (0-32) in the value
stored in rS.  if you append the '.', the condition codes will be updated
so you can quickly tell if the value in rA is zero (meaning the high-bit
of rS is set).


there is also a doubleword version (cntlzd) that will work on
64-bit quantities, but it exists only on 64-bit PowerPC implementations,
eg: the 620.


-gary j kacmarcik
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Sigurdur Asgeirsson)
Date: 25 Mar 1994 20:56:45 GMT
Organization: University of Iceland

In <[e-mail]> [e-mail] (Gary Kacmarcik) writes:


>In article <2mskct$[e-mail]> Chris Russo <[e-mail]> writes:

>>  I need to find the high bit in a long as quickly as possible.
>>  1. I could brute-force shift left till negative.
>>  2. I could brute-force shift right till zero.
>>  3. I could create a 256 byte lookup table and do 1-4 lookups.
>>  4. Someone on the net could show me some neat new algorithm, like
>>      (number)>>(number>>1) ^ number = solution.  There HAS to be
>>      something like that out there somewhere. :-)

>well, i'm not sure if this is of value to you, but if you can assume
>that you're on a PowerPC-based Mac, you can use the cntlzw (Count
>Leading Zeros Word) instruction.

[snip]

  On the >=68020 there is a similar BFFO (bitfield find first one)
instruction that will find the first 1 bit in a bit field (register if
you will).
--
Sigurdur Asgeirsson    | "Well you know, C isn't that hard, void (*(*f[])())()
Kambasel 26            | for instance declares f as an array of unspecified
109 Reykjavik, Iceland | size, of pointers to functions that return pointers to
[e-mail]     | functions that return void... I think"

+++++++++++++++++++++++++++

>From [e-mail] (Tim Smith)
Date: 26 Mar 1994 08:53:28 GMT
Organization: University of Washington School of Law, Class of '95

Chris Russo  <[e-mail]> wrote:
>Hi all,
>
>    I need to find the high bit in a long as quickly as possible.
>1. I could brute-force shift left till negative.
>2. I could brute-force shift right till zero.
>3. I could create a 256 byte lookup table and do 1-4 lookups.
>4. Someone on the net could show me some neat new algorithm, like
>    (number)>>(number>>1) ^ number = solution.  There HAS to be
>     something like that out there somewhere. :-)
>
>Thanks in advance,

This *almost* works (rounding problems--maybe they can be fixed), and
is reasonably portable, and might even be fast, if your compiler can
inline log:

    int    FindFirstBit( unsigned long arg )
    {
        return log(arg)/log(2);
    }

This can compile to something like this:

    00000000: 4E56 0000          LINK      A6,#$0000
    00000004: F22E 4014 0008     FLOGN.L   arg(A6),FP0
    0000000A: F23C 5094 0002     FLOGN.W   #$0002,FP1
    00000010: F200 0420          FDIV      FP1,FP0
    00000014: F200 0003          FINTRZ    FP0
    00000018: F200 7000          FMOVE.W   FP0,D0
    0000001C: 4E5E               UNLK      A6
    0000001E: 4E75               RTS

--Tim Smith

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Sat, 26 Mar 1994 18:23:40 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

>In article <2mskct$[e-mail]> Chris Russo <[e-mail]> writes:
>>  I need to find the high bit in a long as quickly as possible.

      Use a BFFFO (Find First One in Bit Field) instruction.  This requires
a 68020 or above.  Check the timing table for your CPU, though; this may
turn out to be slow for large shifts on some CPUs.  The right way to
implement an instruction like this is by using the floating point
normalizer, but this instruction isn't an FPU instruction, so it probably
doesn't.

Alternatively, though, you could write something like

      int ffb(unsigned long n)
      {
      if (n & 0xffff0000)
      {    if (n & 0xff000000) return(tab[n>>24]+24);
        else return(tab[(n>>16)&0xff]+16);
      }
      if (n & 0xff00) return(tab[(n>>8)&0xff]+8);
      else return(tab[n]);
      }

using a pre-built table.

Shifts of multiples of 8 bits are fast on 68K CPUs, so this is reasonably
efficient.  But look at what comes out of the compiler, and make sure
the compiler is smart enough to do this without pushing operands on the
stack.

    Are you doing cryptanalysis, chess, or emulation of some nonstandard
FPU?

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Thomas R. Kimpton)
Date: Tue, 29 Mar 94 00:16:24 GMT
Organization: Digital Technology, International

In article <2mskct$[e-mail]> Chris Russo <[e-mail]> writes:
>Hi all,
>
>    I need to find the high bit in a long as quickly as possible.
>1. I could brute-force shift left till negative.
>2. I could brute-force shift right till zero.
>3. I could create a 256 byte lookup table and do 1-4 lookups.
>4. Someone on the net could show me some neat new algorithm, like
>    (number)>>(number>>1) ^ number = solution.  There HAS to be
>     something like that out there somewhere. :-)
>
>Thanks in advance,
>
>Chris Russo
>
>Note new address -> [e-mail]


long
findHighBit(register unsigned long n)
{
register long bitnum = 0;

    if(n & 0xffff0000){
        bitnum += 16;
        n >>= 16;
    }
    if(n & 0xff00){
        bitnum += 8;
        n >>= 8;
    }
    if(n & 0xf0){
        bitnum += 4;
        n >>= 4;
    }
    if(n & 0xc){
        bitnum += 2;
        n >>= 2;
    }
    if(n & 0x2){
        bitnum += 1;
    }

}

You'd want to check to see if 'n' is zero before calling this, though.

Tom.

--
- -
Tom Kimpton                            [e-mail]
Digital Technology Int.                [phone]
500 W. 1200 South, Orem UT, 84057      FAX [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Ed Walker)
Date: Wed, 30 Mar 1994 14:21:47 GMT
Organization: SAS Institute Inc.


In article <[e-mail]>, [e-mail] (Thomas R. Kimpton) writes:
>In article <2mskct$[e-mail]> Chris Russo <[e-mail]> writes:
>>Hi all,
>>
>>      I need to find the high bit in a long as quickly as possible.
>>1. I could brute-force shift left till negative.
>>2. I could brute-force shift right till zero.
>>3. I could create a 256 byte lookup table and do 1-4 lookups.
>>4. Someone on the net could show me some neat new algorithm, like
>>    (number)>>(number>>1) ^ number = solution.  There HAS to be
>>     something like that out there somewhere. :-)
>>
>>Thanks in advance,
>>
>>Chris Russo
>>
>>Note new address -> [e-mail]
>
>
>long
>findHighBit(register unsigned long n)
>{
>register long bitnum = 0;
>
>       if(n & 0xffff0000){
>               bitnum += 16;
>               n >>= 16;
>       }
>       if(n & 0xff00){
>               bitnum += 8;
>               n >>= 8;
>       }
>       if(n & 0xf0){
>               bitnum += 4;
>               n >>= 4;
>       }
>       if(n & 0xc){
>               bitnum += 2;
>               n >>= 2;
>       }
>       if(n & 0x2){
>               bitnum += 1;
                n >>= 1;            /* Added line */
>       }

        if ( n ) bitnum += 1;       /* Added line */

        return bitnum;              /* Added line */

>
>}
>
>You'd want to check to see if 'n' is zero before calling this, though.
>
>Tom.
>

Good job Tom! I suggest adding the indicated lines above. Your method
numbers the bits from 0 to 31 (right to left) while the additions number
them 1-32 (r-l) and returns zero if none are on.

Ed                                               >'<
                                                (o o)
+---------------------------------------------o0o-U-o0o---------------+
| [e-mail]    (home)     | It is impossible to make anything  |
| [e-mail]  (work)     | foolproof; fools are so ingenious. |
+---------------------------------------------oo0---0oo---------------+





---------------------------

>From [e-mail] (Travis Blalock)
Subject: Generating Activate Events
Date: Tue, 29 Mar 1994 18:59:08 GMT
Organization: HP Labs, High Speed Electronics Dept., Palo Alto, CA


** Warning UI violations in progress **

I am looking at ways of generating activate/deactivate events from a
system extension.  Activate events are not listed in IM as one of the
events I can post with PostEvent or PPostEvent.  Is this a 'real'
limitation or a 'you shouldn't do this' limitiation?  I will just try it
as soon as I get a chance, but I thought I would test the waters here.
I do not want to use SelectWindow because I don't want the window to
come to the top.

Any advice (other than don't do that :-)) appreciated.

Travis
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 29 Mar 1994 20:29:36 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Travis Blalock) writes:

>I am looking at ways of generating activate/deactivate events from a
>system extension.  Activate events are not listed in IM as one of the

LMSetCurActivate() and LMSetCurDeactive()

However, if there's already such an event pending, you're out
of luck.
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
 Santa's Reindeer: Fry 1 minced onion, add 1 lb thinly sliced frozen reindeer,
 fry to color, add 1/2 lb mushrooms and 1/2 lb sour cream, simmer 5 mins, add
 soy to taste, salt, pepper. Serve with boiled rice and tart jelly.

+++++++++++++++++++++++++++

>From [e-mail] (Jim Walker)
Date: 29 Mar 1994 21:20:47 GMT
Organization: University of South Carolina - Columbia - Computer Science


Activate/deactivate are not supposed to be in the event queue, hence you are
not supposed to create them with PostEvent/PPostEvent.  However, for certain
purposes having to do with scrap conversion, I have found it useful to
create activate events with PPostEvent, and have not seen any obvious ill
effects.  I don't think I ever tried it for a window that's not the front
window, though.  As always, "your mileage may vary."
--

 -- Jim Walker  USC Dept. of Math.  [e-mail]

---------------------------

>From Willie Rauchwerger <[e-mail]>
Subject: I got my PPC PDS card...
Date: 30 Mar 1994 15:26:21 GMT
Organization: OU Health Sciences Center

Well, I got my PPC PDS card for my Quadra 700 yesterday. I know
not many people (if any) have posted their experiences with the
card, and I thought I might give a bit of an overview.

In the box, their are three major items:

- the PDS cad
- a 610-PDS adaptor for the card
- System 7.1.2

Installing it was pretty easy - pop open the Quadra, decide what
NuBus card I was going to lose, and put the card in the PDS slot.

Then, boot from the install disk, and let it upgrade your system
to System 7.1.2. (Now I did this on my portable drive I bring to
work, and I can verify that System 7.1.2 does boot for 68k machines
as well. As I booted off it to type this post...)

System 7.1.2 is basically a minor rev to support PowerPC. Very, very
little is native as far as control panels, extensions, the finder,
etc. As a matter of fact, the finder is completely emulated, and
every control panel and extension I looked at (I may have missed a
few) were 68k binaries. No code fragments to be found.

Except in the "PowerPC Upgrade Card Enabler"...it is a 420k file,
that some interesting things inside of it. In the "fovr" resource,
I assume I found Native QuickDraw (NQD), and the new native Memory
Manager...also I found maybe a native on-board video display driver?
I am not sure whether or not it was replacing the one in the
system or not.

Oh, yeah, the QuickTime native codecs are in the QuickTime power
plug...yes, it is very fast...

I digress...after you perform the update, reboot. My Quadra booted
into the 68k enviroment, since I hadn't a chance to set the control
panel to reboot from the PDS card.

Set the control panel and shutdown. Restart doesn't cut it - anytime
you switch between the PDS and the 040, you have to shutdown. I
assume some pram thing...

Power on. A really killer startup sound. And it isn't the new
Stanley Jordan one, nor is it the old Quadra one, or the AV one...
I think this one is great...

OK, I know, how did it work? Well, about as I expected in emulation.
I ran my normal software and it was a bit slower than my 040. However,
my heavily reliant on QuickDraw things, (some of my own software
that pegs CopyBits, etc. and others) were very fast. ClarisWorks for
68k seemed no different than on the 040.

I found one problem...Think C 6.01 won't compile...not that it is
a big issue for me...I jumped to Metrowerks for most of my stuff
now anyway.

Metrowerks C++ for PPC was great. I had worked on getting my
software ready for it, and I just love it. It is really repsonsive,
and compiles very, very fast. A project that was taking approx
2:00 min to compile under Think on a Q800, 1:15 min under
Metrowerks on a Q800, took 28 secs on Metrowerks for PPC on my
upgrade card.

Wow.

I was also concerned about how fast it would be accessing memory
that was on the main board, so I wrote some stuff to work with
8mb pointer, and the PPC card was still about 3 times faster than
with my Q700 with the 040 running.

I know this is a bit rambling, but I didn't know what everyone
would be interested in...I will try to answer any questions anyone
has about it.

Bottom line: It seemed almost as fast as the Q700 in emulation, and
was 2-3 faster in native software.

Well, worth the $650 bucks...

- -----------------------------------------------------------------
Willie Rauchwerger         AppleLink: Willie
Telemedicine Software Guy  Internet:  [e-mail]
OU Health Sciences Center

---------------------------

>From [e-mail] (Kent Miller)
Subject: Moving an editText area in a Modal Dialog Q
Date: Mon, 28 Mar 1994 05:01:46 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)


Can anyone tell me how to move an editText area in a modal dialog?

A little background:  I am writing a code resource to put up a dialog for
user input.  Since I didn't want to go to the hassle of making sure that
all the resources got moved with the code resource, I decided to use
NewDialog instead of making dialog resources.

To have an item list, I made one in resedit, then copied the hex and
put it with the code.  When I want to use it, I just make a new handle
and copy the list data in it, then pass that to NewDialog.

This works pretty well and I can move buttons around to my hearts content
(after I figured out that you had to call SetDItem and MoveControl to do it.)

But, now I need to move the editText area.

Any help would be appreciated.

Kent


--
____________________________________________________________
[e-mail] | Macintosh Software Engineer
____________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Nicholas Jackiw)
Date: 29 Mar 1994 17:59:42 GMT
Organization: The Whole Earth 'Lectronic Link, Sausalito, CA

In article <[e-mail]>,
Kent Miller <[e-mail]> wrote:
>
>Can anyone tell me how to move an editText area in a modal dialog?
>
>Kent

If you need to move them only once (i. e. "to final position"),
simply use SetDItem(theDlog, theItem, ... theRect), where theRect
is computed to be the desired location of the editText item in
dialog-local coordinates. Do this before you ShowWindow(theDlog)
and things look dandy.

If you need to move an edit text item while the dialog is showing,
it's more complicated. If the edit text happens to be the one
currently in use by the user (not necessarily the case if there
are >1 edit text items), you need to treat DialogPeek(theDlog)^.textH
as an active TEdit control and update its viewRect and destRect.
(The user is currently using edit text item DialogPeek(theDlog)^.editField+1.)

A more elegant approach, in this second case, would
be to use multiple edit text boxes, one at Location 1 and one at
Location 2, etc. Use HideDItem and ShowDItem to determine which one
is visible at any given time.

Is this the sort of info you wanted?


--
                              --- * ---
Nick Jackiw                  [e-mail]   | [e-mail]
Key Curriculum Press, Inc.   Applelink:KEY.EDUSOFT | [phone]
                              --- * ---

+++++++++++++++++++++++++++

>From [e-mail] (Marcel Blonk)
Date: Tue, 29 Mar 1994 22:10:06 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Kent Miller ([e-mail]) wrote:

: Can anyone tell me how to move an editText area in a modal dialog?

Here's a copy of the method I use to move dialog items:


void CDialog::SetDRect( short item, Rect *r)
{
short       type;
Handle      h;
Rect        rr;

    GetDItem( window, item, &type, &h, &rr);
    SetDItem( window, item, type, h, r);
    type &= ~itemDisable;
    if ( (type & ~0x3) == ctrlItem )
    {   MoveControl( (ControlHandle)h, r->left, r->top);
        SizeControl( (ControlHandle)h, r->right - r->left, r->bottom -
r->top);
    }
    else if ( type == editText )
    {   if ( item == (((DialogPeek)window)->editField + 1) )
        {   if ( ((DialogPeek)window)->textH != nil )
            {   OffsetRect( &(*((DialogPeek)window)->textH)->destRect,
                            r->left - rr.left, r->top - rr.top);
                OffsetRect( &(*((DialogPeek)window)->textH)->viewRect,
                            r->left - rr.left, r->top - rr.top);
                OffsetRect( &(*((DialogPeek)window)->textH)->selRect,
                            r->left - rr.left, r->top - rr.top);
            }
        }
    }
}

Hope this helps,

Marcel


---------------------------

>From [e-mail] (Brian C. Burke)
Subject: PPC Development and MPW Tools
Date: Thu, 24 Mar 1994 23:02:09 -0800
Organization: UC Berkeley

 Will any of the available PowerPC development environments allow
development and execution of (MPW like) tools in PowerPC native code.

Brian

+++++++++++++++++++++++++++

>From [e-mail] (Michael Peirce)
Date: Mon, 28 Mar 94 10:17:35 PST
Organization: Peirce Software, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Brian C. Burke) writes:
>  Will any of the available PowerPC development environments allow
> development and execution of (MPW like) tools in PowerPC native code.

How about MPW?  Apple has said they will be shipping some native
MPW tools real-soon-now.  I'm not holding my breath, but it should
take them too long to do this for some of the more important tools.


-- Michael Peirce        -- [e-mail]
-- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301
--                       -- San Jose, California USA 95117
-- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: [phone]
--    Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

>From [e-mail] (Language Systems)
Date: Tue, 29 Mar 1994 14:23:30 GMT
Organization: PC Three, Inc.

[e-mail] (Michael Peirce) writes:


>In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Brian C. Burke) writes:
>>  Will any of the available PowerPC development environments allow
>> development and execution of (MPW like) tools in PowerPC native code.

>How about MPW?  Apple has said they will be shipping some native
>MPW tools real-soon-now.  I'm not holding my breath, but it should
>take them too long to do this for some of the more important tools.

Language Systems will soon be shipping 2 development tools for the
PowerMacs.

LS Pascal/PPC
LS FORTRAN/PPC

Both run with MPW and will be native on the PowerMac.

Lisa Jones
Language Systems
800-252-6479 (for more info)

+++++++++++++++++++++++++++

>From Manuel Veloso <[e-mail]>
Date: Wed, 30 Mar 1994 06:35:07 GMT
Organization: Ibex Productions

In article <[e-mail]> Michael Peirce,
[e-mail] writes:
>How about MPW?  Apple has said they will be shipping some native
>MPW tools real-soon-now.  I'm not holding my breath, but it should
>take them too long to do this for some of the more important tools.

Last I heard, MPW was going to be native near the end of the year. This
is from a friend who called & asked APDA about it, since he was also
asking about his Mac on RISC disc upgrade.

This is kind of ridiculous at first glance, but a few weeks ago I was looking
at the funky stuff MPW had to do for tool support, and well, I understand
why converting that might take a while. Then again, there's probably an alpha
floating around out there somewhere, since Apple's never been shy about
keeping tools in the alpha/beta state for a while.

---------------------------

>From [e-mail] (Dave Falkenburg)
Subject: PowerMac Programming
Date: 16 Mar 94 02:04:58 GMT
Organization: (none)

Organization: Apple Computer, Inc.

In article <[e-mail]> Robert S. Mah,
[e-mail] writes:
> From the Mart 94 AppleDirections newsletter...
>
> Macintosh With PowerPC Bundle (B1864LL/A)                   $849.00
> Programmer's Introduction to RISC and PowerPC (R0172LL/A)   $150.00
> Macintosh with PowerPC Starter Kit (R0563LL/A)               $39.95
>

Gack. That!s ALOT of money.

Seems like E.T.O. should come with all this stuff, wouldn't you think?

-Dave Falkenburg

Disclaimer: I don!t speak for Apple in this post, although someone who
think!s that the SDK is worth $850 bucks probably would.

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Fri, 25 Mar 1994 16:37:12 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

[e-mail] (Dave Falkenburg) writes:
>Organization: Apple Computer, Inc.
>In article <[e-mail]> Robert S. Mah,
>[e-mail] writes:
>> From the Mart 94 AppleDirections newsletter...
>>
>> Macintosh With PowerPC Bundle (B1864LL/A)                   $849.00
>> Programmer's Introduction to RISC and PowerPC (R0172LL/A)   $150.00
>> Macintosh with PowerPC Starter Kit (R0563LL/A)               $39.95
>>
>Gack. That!s ALOT of money.

     Keeps the rabble out.  Can't have just anybody developing PowerPC
apps.

     I still haven't seen a single PowerPC app in shrink-wrap form on
a store shelf, but I talked to somebody who said that they knew somebody
who had seen one.

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Sat, 26 Mar 1994 01:50:31 GMT
Organization: Adobe Systems Incorporated

John Nagle writes
>      I still haven't seen a single PowerPC app in shrink-wrap form on
> a store shelf, but I talked to somebody who said that they knew somebody
> who had seen one.

How about every copy of Photoshop 2.5.1 on store shelves? With the Power
Macintosh accelerator (avaiable free on the net, as well as elsewhere) this
product delivers the performance a straight Power Macintosh port would
deliver for most operations.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
"Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins)

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Sat, 26 Mar 1994 18:02:30 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

[e-mail] (Zalman Stern) writes:
>John Nagle writes
>>      I still haven't seen a single PowerPC app in shrink-wrap form on
>> a store shelf, but I talked to somebody who said that they knew somebody
>> who had seen one.

>How about every copy of Photoshop 2.5.1 on store shelves? With the Power
>Macintosh accelerator (avaiable free on the net, as well as elsewhere) this
>product delivers the performance a straight Power Macintosh port would
>deliver for most operations.

      I'm talking about product marketing.  Yes, there's stuff you can get
by mail-order.  But I'm not seeing retailers committing shelf space to
PowerPC software.

      Besides, the Photoshop "accelerator" isn't a full port; it's just
faster versions of a few of the slower filters.

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Brian Lowry)
Date: 26 Mar 1994 21:29:44 GMT
Organization: Chem Eng - Univ of Alberta

In article <[e-mail]>, [e-mail] (John Nagle)
wrote:

> [e-mail] (Zalman Stern) writes:
> >John Nagle writes
> >>      I still haven't seen a single PowerPC app in shrink-wrap form on
> >> a store shelf, but I talked to somebody who said that they knew somebody
> >> who had seen one.

> >How about every copy of Photoshop 2.5.1 on store shelves? With the Power
> >Macintosh accelerator (avaiable free on the net, as well as elsewhere) this
> >product delivers the performance a straight Power Macintosh port would
> >deliver for most operations.

>       I'm talking about product marketing.  Yes, there's stuff you can get
> by mail-order.  But I'm not seeing retailers committing shelf space to
> PowerPC software.

>       Besides, the Photoshop "accelerator" isn't a full port; it's just
> faster versions of a few of the slower filters.

  I guess this means that almost every single filter built into Photoshop
is one of the slower ones... where are the faster filters hiding?

  Before you go any further showing your massive misunderstanding of
PowerPC programming, perhaps you ought to consider that a port to the
PowerPC does not require 100% native code.  All that is required is native
code which patches the most processor intensive portions of an application.
 This is essentially what the Photoshop plug-in does, hence Photoshop is
now native.  Demanding 100% PowerPC code makes about as much sense as
demanding that programmers stop using Quickdraw and write something more
efficient... both Quickdraw and 680x0 emulation are built in, and there's
no reason to reinvent the wheel for something like a 5% speed improvement.

btw - before I get jumped on, yes I do know that Photoshop doesn't use
Quickdraw exclusively, but then, Quickdraw doesn't support CMYK :)

--

Brian Lowry

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Sun, 27 Mar 1994 09:42:27 GMT
Organization: Adobe Systems Incorporated

John Nagle writes
[I still haven't seen a single PowerPC app in shrink-wrap form on a store
shelf.]

I wrote:
[How about Photoshop 2.5.1 plus the Power Macintosh accelerator?]

John Nagle writes
>       I'm talking about product marketing.  Yes, there's stuff you can get
> by mail-order.  But I'm not seeing retailers committing shelf space to
> PowerPC software.

New copies of Photoshop 2.5.1 are shipping with the Power Macintosh
accelerator in the package. This product provides the winning feature of a
Power Macintosh (i.e. speed). It doesn't matter that it is not completely
native. (And before you complain that it would be slightly faster if it were
fully native, keep in mind that Apple made the same decision about their
OS.) I'm not sure if the boxes will have a sticker on them saying "Includes
Power Macintosh support" or whatever.

>       Besides, the Photoshop "accelerator" isn't a full port; it's just
> faster versions of a few of the slower filters.

I generally don't tell other people what code they wrote does unless I'm
*damn* sure I know what I'm talking about. I expect you to afford me the
same courtesy. The accelerator provides native implementations of almost
every routine that is written in 68K assembly for 2.5.1. Considering the
quality of Macintosh compilers, it it was speed critical, a routine got
written in assembly. (Note: the main failing of the accelerator is it
provides minimal speedup for plug-in filters. These run at emulated speed.)

The accelerator provides around 90% of the speed benefit of a full native
application with minimal impact on the memory footprint. (I know this
because we did a bunch of measurements to make the comparison.) The QA
effort for the accelerator product is relatively small. (Which is incredibly
important given the limited beta testing opportunities.) The distribution
plan is easy: anybody who wants one can have one because to get any value
from it they need a copy of 2.5.1. In short, its an excellent engineering
answer to the overhead of doing a complete new release of a product that's
been shipping for a year to support a new piece of hardware. (When the full
native version ships, it will be faster than the accelerator, but that has
more to do with my improving the code between the products shipping.)

The idea of allowing speed critical functions to be replaced at runtime and
its implementation in Photoshop is due to Mark Hamburg and Thomas Knoll. The
underlying technology that allows this replacement on PowerPC is Mixed Mode,
implemented by various people at Apple (or formerly at Apple :-)) including
Sean Parent and Bruce Jones. Given these two great ideas, I didn't have to
think very hard to come up with the idea of this accelerator.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
"Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins)

+++++++++++++++++++++++++++

>From [e-mail]
Date: 29 Mar 94 13:36:14 MST
Organization: (none)

In article <[e-mail]>, [e-mail] (Dave Falkenburg) writes:
> Organization: Apple Computer, Inc.
>
> In article <[e-mail]> Robert S. Mah,
> [e-mail] writes:
>> From the Mart 94 AppleDirections newsletter...
>>
>> Macintosh With PowerPC Bundle (B1864LL/A)                   $849.00
>> Programmer's Introduction to RISC and PowerPC (R0172LL/A)   $150.00
>> Macintosh with PowerPC Starter Kit (R0563LL/A)               $39.95
>>
>
> Gack. That!s ALOT of money.
>
> Seems like E.T.O. should come with all this stuff, wouldn't you think?
>
> -Dave Falkenburg
>
> Disclaimer: I don!t speak for Apple in this post, although someone who
> think!s that the SDK is worth $850 bucks probably would.

Do NOT buy the Programmer's Intro to RISC!!!!!


Honest. It is a waste of money. I am working on a shareware product (also done
in HyperCard) which will be worth far more and cost 1/10 as much.

Lawson

+++++++++++++++++++++++++++

>From [e-mail] (Rich Siegel)
Date: Wed, 30 Mar 1994 03:33:56 GMT
Organization: Bare Bones Software

In article <[e-mail]> [e-mail] writes:

>Do NOT buy the Programmer's Intro to RISC!!!!!
>
>
>Honest. It is a waste of money. I am working on a shareware product (also done
>in HyperCard) which will be worth far more and cost 1/10 as much.
>
>Lawson

...and which will enrich your bottom line, or so you hope.

Be sure that when posting, you make your articles as biased and
content-free as possible, lest someone mistake your motives.

R.

(warning: the above may cause cognitive dissonance for the sarcasm-impaired.)

--
Rich Siegel % [e-mail]    % Principal, Bare Bones Software
--> For information about BBEdit, finger [e-mail] <--

"...yeah, I inhaled, and then I drank the bong water. So what're
you gonna do about it?" - Dennis Miller, on Bill Clinton

---------------------------

>From [e-mail] (Steve Byan)
Subject: PowerMacs and ARTA
Date: 21 Mar 1994 19:30:16 GMT
Organization: Hitachi Computer

So what's happened to ARTA in the PowerMacs? How do I write real-time DSP
code for the 601? (I'm not interested in purchasing a 3210 add-in card for
the PowerMacs.)

Steve Byan                                  internet: [e-mail]
Hitachi Computer Products (America), Inc.
1601 Trapelo Road                           phone: [phone]
Waltham, MA 02154                           FAX: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 23 Mar 94 10:05:25 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Steve Byan) writes:
> So what's happened to ARTA in the PowerMacs? How do I write real-time DSP
> code for the 601? (I'm not interested in purchasing a 3210 add-in card for
> the PowerMacs.)

Last I heard ARTA is included with the PowerMacs, only there is no DSP for
them to talk to (you have to buy add-in cards for that).

As for writing real-time DSP code for a general-purpose CPU, good luck...

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Wed, 23 Mar 1994 05:00:05 GMT
Organization: Adobe Systems Incorporated

Lawrence D'Oliveiro, Waikato University writes
> In article <[e-mail]>, [e-mail] (Steve Byan)
writes:
> > So what's happened to ARTA in the PowerMacs? How do I write real-time
DSP
> > code for the 601? (I'm not interested in purchasing a 3210 add-in card
for
> > the PowerMacs.)
>
> Last I heard ARTA is included with the PowerMacs, only there is no DSP for
> them to talk to (you have to buy add-in cards for that).

The 'rtmr' gestalt selector is undefined on the Power Macintosh. I assume
third-party DSP cards provide ARTA themselves as they do for non-AV 68K
Macs.

> As for writing real-time DSP code for a general-purpose CPU, good luck...

This has a lot more to do with the OS software than the CPU.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
"Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins)

+++++++++++++++++++++++++++

>From [e-mail] (Steve Byan)
Date: 23 Mar 1994 17:58:37 GMT
Organization: Hitachi Computer

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) wrote:
>
> In article <[e-mail]>, [e-mail] (Steve Byan) writes:
> > So what's happened to ARTA in the PowerMacs? How do I write real-time DSP
> > code for the 601? (I'm not interested in purchasing a 3210 add-in card for
> > the PowerMacs.)
>
> Last I heard ARTA is included with the PowerMacs, only there is no DSP for
> them to talk to (you have to buy add-in cards for that).
>
> As for writing real-time DSP code for a general-purpose CPU, good luck...

Apple claims to ship real-time speech-recognition, speech synthesis, and
9600 baud modem code with the PowerMacs - using only the 601 - not using
any DSP chip. Supposedly the 601 can do multiply-accumulates faster than
the 3210.

The remaining question is "by what mechanism am I supposed to schedule
real-time (DSP) code that executes on the 601, and processes sound
samples?". For the AV Macs, the answer was "use ARTA". My hope is that the
same API applies for the PowerMacs.

Does anyone have any real information they can pass on?

Thanks,
-Steve

Steve Byan                                  internet: [e-mail]
Hitachi Computer Products (America), Inc.
1601 Trapelo Road                           phone: [phone]
Waltham, MA 02154                           FAX: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Amanda Walker)
Date: Wed, 23 Mar 1994 16:08:20 -0500
Organization: InterCon Systems Corporation, Herndon, VA USA

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> Last I heard ARTA is included with the PowerMacs, only there is no DSP
> for them to talk to (you have to buy add-in cards for that).

ARTA is not present.  There is evidently some real-time code in them (used
by the Power Macintosh Geoport software, for example), but it is so far
undocumented.

> As for writing real-time DSP code for a general-purpose CPU, good
> luck...

Indeed.  I get sound dropouts on my 8100/80 if the CPU gets busy.
I'm sticking with my 660AV for anything involving audio for the time being.


Amanda Walker
Advanced Projects
InterCon Systems Corporation



+++++++++++++++++++++++++++

>From [e-mail] (Amanda Walker)
Date: Wed, 23 Mar 1994 16:09:26 -0500
Organization: InterCon Systems Corporation, Herndon, VA USA

[e-mail] (Steve Byan) writes:
> For the AV Macs, the answer was "use ARTA". My hope is that the same API
> applies for the PowerMacs.

It does not.  Any real-time API that may exist on Power Macintosh machines
is currently undocumented.  There's always the Time Manager, I suppose :-P.


Amanda Walker
Advanced Projects
InterCon Systems Corporation



+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 25 Mar 94 14:27:54 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Amanda Walker) writes:
> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>> Last I heard ARTA is included with the PowerMacs, only there is no DSP
>> for them to talk to (you have to buy add-in cards for that).
>
> ARTA is not present.  There is evidently some real-time code in them (used
> by the Power Macintosh Geoport software, for example), but it is so far
> undocumented.
>
>> As for writing real-time DSP code for a general-purpose CPU, good
>> luck...
>
> Indeed.  I get sound dropouts on my 8100/80 if the CPU gets busy.
> I'm sticking with my 660AV for anything involving audio for the time being.

(Gloat, gloat.) I'd just like to repeat a couple of statements I made on
comp.sys.mac.hardware:

* N + 1 processors are better than N. You can usually find a way to make use
of more processors to run things in parallel.

* A purpose-built processor is inherently superior to a general-purpose one
_for that particular purpose_. People keep talking about how "DSP-like" the
PowerPC is, just because it can do a multiply-and-add in one instruction. But
there's more to a DSP than that.

Put these two together, and the conclusion is inescapable: Apple is going
to have to return to the multiple-processor approach, and bring out Power Macs
with DSPs in them.

When that happens, I might be tempted to give up my 840AV...

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From [e-mail] (James McCartney)
Date: 25 Mar 1994 14:27:43 GMT
Organization: McDonald Observatory, University of Texas @ Austin

In article <[e-mail]>,
Amanda Walker <[e-mail]> wrote:

>  Any real-time API that may exist on Power Macintosh machines
>is currently undocumented.  There's always the Time Manager, I suppose :-P.


    Having not used the Time Mgr, what does it really guarantee in
terms of max delay, etc?  How reliable would using the callback
routines in the double buffering sound routines be?

  --- james mccartney



+++++++++++++++++++++++++++

>From [e-mail] (Andrew Bevin)
Date: 26 Mar 1994 07:34:32 GMT
Organization: data visual software

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) wrote:

...
>
> Put these two together, and the conclusion is inescapable: Apple is going
> to have to return to the multiple-processor approach, and bring out Power Macs
> with DSPs in them.
>
> When that happens, I might be tempted to give up my 840AV...
>
> Lawrence D'Oliveiro                       fone: [phone]
> Info & Tech Services Division              fax: [phone]
> University of Waikato            electric mail: [e-mail]
> Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

So what happened to the centris 650 with the Video Spigot?

Andrew "Just keeping tabs" Bevin

--
[e-mail] -- "I've a Plan so cunning you could put a tail on it
    and call it a weasel" - BlackAdder

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Sun, 27 Mar 1994 03:06:35 GMT
Organization: Adobe Systems Incorporated

Lawrence D'Oliveiro, Waikato University writes
> (Gloat, gloat.) I'd just like to repeat a couple of statements I made on
> comp.sys.mac.hardware:

Gloating seldom improves the rigor of one's arguments.

> * N + 1 processors are better than N. You can usually find a way to make
use
> of more processors to run things in parallel.

The above statement is simply not true. First off, N + 1 processors cost
more than N (for positive N :-)). In the case of going from N=1 to N=2, the
expense is more than the added cost of another processor as external
hardware must be added and significant software development costs must be
amortized.

In the performance realm, there are plenty of examples of parallelized
software running slower than a uniprocessor version. There are two primary
reasons for this: communication overhead and slower hardware. Communication
overhead involves the obvious issue of synchronizing separate processes and
transferring data from one processor to another. (Even if they share memory,
cache issues must be taken into account.)

The slower hardware issue is more interesting. Generally, simpler hardware
has a faster design cycle and is cheaper to produce. The result of this is
that for a given amount of money in a given timeframe, a uniprocessor
machine will be faster than the individual processors in a multiprocessor
box. Unless you're application takes good advantage of the multiprocessor,
it will run faster on the uniprocessor. This is especially relevant for a
heterogeneous multiprocessor like the 840AV where it is more difficult (and
much less portable) to split one's application between different CPUs.

> * A purpose-built processor is inherently superior to a general-purpose
one
> _for that particular purpose_.

The DSP subsystem in Apple's AV Macs attempts to be general purpose. By the
time all is said and done, it has to support telecommunications, audio
processing, and image processing. A whole real-time OS and software
architecture is required to implement all this. Furthermore, since it is
exported to applications software, lots of flexibility in hardware
implementation is lost since future platforms have to be compatible. The
subsystem is most specialized for telecom applications. Which is nice,
except that I can get that functionality with cost effective add-on modem
hardware.

In contrast, when SGI (a company noted for strong multi-media support) built
hardware with an embedded DSP, they did not export interfaces to the DSP
directly. Rather they provided high-level libraries to implement signal
processing functionality. They now ship R4000 based machines without a DSP
and old software works fine.

> People keep talking about how "DSP-like" the
> PowerPC is, just because it can do a multiply-and-add in one instruction.
But
> there's more to a DSP than that.

PowerPC provides a number of other features which are useful for
implementing signal processing codes such as zero overhead loops and update
addressing modes. The only DSP like thing that is really missing is
efficient methods of converting floating-point numbers into common signal
data formats (e.g. 8 and 16 bit integers, u law and A law 8 bit formats).
The architecture also makes it difficult to cheaply implement as much memory
bandwidth as the DSP3210 has. However, the DSP3210 architecture basically
mandates a certain pipeline and other features which make it fairly
inflexible.

> Put these two together, and the conclusion is inescapable: Apple is going
> to have to return to the multiple-processor approach, and bring out Power
Macs
> with DSPs in them.

The problem Apple has now is running anything remotely real-time on the same
processor as their system software. One solution to this is adding another
processor to the box. Another solution is to write better system software.
If they do add more hardware to the box, there is nothing that says it has
to be a DSP3210. (For example, a 603 or one of the new PowerPC
implementations targeted at the embedded market would probably work as well
and be a lot easier to develop software for.)

> When that happens, I might be tempted to give up my 840AV...

My two favorite quotes on the 840AV: "It sucketh mightily." and "The IIfx of
the 90's."

I've tried programming the DSP3210 and I have lots of experience with
PowerPC. I'll take PowerPC anytime thank you.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
"Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins)

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 28 Mar 1994 13:44:02 -0800
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Zalman Stern) writes:

>I've tried programming the DSP3210 and I have lots of experience with
>PowerPC. I'll take PowerPC anytime thank you.


Besides, I you can get a PPC compiler for about $300.00. The DSP
compiler is about $1000.00. Ouch!



Xavier

--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 29 Mar 94 11:54:55 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Zalman Stern) writes:
> Lawrence D'Oliveiro, Waikato University writes
>> * N + 1 processors are better than N. You can usually find a way to make
> use
>> of more processors to run things in parallel.
>
> The above statement is simply not true. First off, N + 1 processors cost
> more than N (for positive N :-)).

Nevertheless, according to our shop price lists, a 6100/60AV is significantly
more expensive than a 660AV.

> In the performance realm, there are plenty of examples of parallelized
> software running slower than a uniprocessor version. There are two primary
> reasons for this: communication overhead and slower hardware.

No, the primary reason is dumbass programmers who think that they *must*
run everything in parallel, just because they can. That extra processor gives
you the choice: the trick is knowing when to take it.

> The slower hardware issue is more interesting. Generally, simpler hardware
> has a faster design cycle and is cheaper to produce.

See above re prices.

>> * A purpose-built processor is inherently superior to a general-purpose
> one
>> _for that particular purpose_.
>
> The DSP subsystem in Apple's AV Macs attempts to be general purpose. By the
> time all is said and done, it has to support telecommunications, audio
> processing, and image processing. A whole real-time OS and software
> architecture is required to implement all this. Furthermore, since it is
> exported to applications software, lots of flexibility in hardware
> implementation is lost since future platforms have to be compatible.

I see your point about things like DSP libraries. That would have been a
good thing to add, and I don't think it's too late to do so.

> The
> subsystem is most specialized for telecom applications. Which is nice,
> except that I can get that functionality with cost effective add-on modem
> hardware.

The nicest thing I can say is that this is a short-sighted view.

>
>> Put these two together, and the conclusion is inescapable: Apple is going
>> to have to return to the multiple-processor approach, and bring out Power
> Macs
>> with DSPs in them.
>
> The problem Apple has now is running anything remotely real-time on the same
> processor as their system software.

No way can you get the performance this way, as some PowerMac users are already
discovering. Keeping the real-time and non-real-time stuff on separate
processors is the way to go.

>> When that happens, I might be tempted to give up my 840AV...
>
> My two favorite quotes on the 840AV: "It sucketh mightily." and "The IIfx of
> the 90's."

I've had a IIfx for several years. And I've had an 840AV for about a month
now. I'll take the 840AV anytime thank you.

> I've tried programming the DSP3210 and I have lots of experience with
> PowerPC. I'll take PowerPC anytime thank you.

We do DSP programming not because it is easy, but because it is hard...

Lawrence
(still gloating)

---------------------------

>From [e-mail] (Stephen Marshall)
Subject: Quickdraw GX Beta 3
Date: 18 Mar 1994 03:21:19 GMT
Organization: Victoria University of Wellington

Hi,

I have just tried to run this off the March Developers CD and got a finder
error 41 (could not load finder?). Has anyone else encountered this
problem? Happens on a 660av and an LC475 with a new install of System 7.1.

Stephen Marshall
--
Macintosh Consultant                              [e-mail]
Victoria University of Wellington
New Zealand

+++++++++++++++++++++++++++

>From [e-mail] (Glenn Andreas)
Date: Sat, 19 Mar 1994 15:16:23 GMT
Organization: SCTC

[e-mail] (Stephen Marshall) writes:

>Hi,

>I have just tried to run this off the March Developers CD and got a finder
>error 41 (could not load finder?). Has anyone else encountered this
>problem? Happens on a 660av and an LC475 with a new install of System 7.1.

>Stephen Marshall

I've had the exact same problem.  You can just hit "g" from MacsBug and it
will eventually bring up an alert saying "Couldn't load QuickDraw GX,." or
something like that.

What is happening is that the QuickDraw GX file is compressed on the CD and
when the installer goes to expand it, something goes wrong, which results
in resource fork being hosed.  The finder goes to open the resource fork,
and fails, thus the message.

However, I don't know why the installer doesn't expand it correctly - I've
yet to get it to work (I've tried on different machines (though all C610
running either 7.1 or 7.1 Pro) with different CD Roms, tried moving the
installer stuff to hard drive, etc...)  What is strange is that the results
of the different attempts often different.  Basically, something is being
expanded too big (the file is larger, usually by some value that is a
multiple of at least $100, often $1000) and so doesn't work as a resource
file - I've even tried changing the header information to point to where
the resmap ends up, but upon opening it with ResEdit, only about half the
resources can be salvaged.

I was guessing it was just me, since I hadn't seen anything posted here
about it (though I find it difficult to believe that a CD can be "bad",
that was one of the constants between all installs), and the next mailing
is due in a week or so, I figured I'd just try again then.

Glenn Andreas


+++++++++++++++++++++++++++

>From [e-mail] (Brian Clark)
Date: Sat, 19 Mar 1994 18:15:52 -0600
Organization: Northwestern University

In article <[e-mail]>, [e-mail] (Glenn
Andreas) wrote:

> [e-mail] (Stephen Marshall) writes:

> I was guessing it was just me, since I hadn't seen anything posted here
> about it (though I find it difficult to believe that a CD can be "bad",
> that was one of the constants between all installs), and the next mailing
> is due in a week or so, I figured I'd just try again then.

I've had something similar happen. Everything loads fine at startup, and
seems to work, but DiskFix complains about the QD GX extension file length
being wrong. Making a copy of the file, then replacing the active version
with the copy usually works, but I have had the error message reccur.

+++++++++++++++++++++++++++

>From Jaime Prilusky <[e-mail]>
Date: Sun, 20 Mar 1994 15:16:04 GMT
Organization: Weizmann Institute of Science

In article <[e-mail]> Stephen
Marshall, [e-mail] writes:
>I have just tried to run this off the March Developers CD and got a
finder
>error 41 (could not load finder?). Has anyone else encountered this
>problem? Happens on a 660av and an LC475 with a new install of System
7.1.

 Please check if you have installed the WunderBar Control pannel. I had
the same
 problem, even with MPW, until we removed it.

 Dr Jaime Prilusky, Head
 Bioinformatics Unit                 ! [e-mail]
 Weizmann Institute of Science       ! fax: [phone]
 76100 Rehovot - Israel              ! tel: [phone]

+++++++++++++++++++++++++++

>From [e-mail]
Date: 21 Mar 94 12:09:51 -0600
Organization: Fermi National Accelerator Lab

In article <[e-mail]>, Jaime Prilusky <[e-mail]> writes:
> In article <[e-mail]> Stephen
> Marshall, [e-mail] writes:
>>I have just tried to run this off the March Developers CD and got a
> finder
>>error 41 (could not load finder?). Has anyone else encountered this
>>problem? Happens on a 660av and an LC475 with a new install of System
> 7.1.
 I too had this problem on my SE/30.  A clean install of sys 7.1 didn't fix
it, however, careful dusting and wiping of the cd did....  I swear!  It
was as if some bad data came off my cd.  The bomb was reproducable (sp) and
I repeated the install (of sys 7 and GX) three times before I "cleaned" my
CD and off it went.  I was using the GX Beta 3 off of develop, by the way.
My se/30 has 5 megs (can you say "virtual memory").
  I've seen this happen before -- nonsense characters in header files,
for example.  I'm not sure why the CD didn't do error checking on the file.

    Cheers,
        Gordon ([e-mail])


+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 22 Mar 94 17:46:05 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Glenn Andreas) writes:
>
> What is happening is that the QuickDraw GX file is compressed on the CD and
> when the installer goes to expand it, something goes wrong, which results
> in resource fork being hosed.  The finder goes to open the resource fork,
> and fails, thus the message.
>
> However, I don't know why the installer doesn't expand it correctly - I've
> yet to get it to work (I've tried on different machines (though all C610
> running either 7.1 or 7.1 Pro) with different CD Roms, tried moving the
> installer stuff to hard drive, etc...)  What is strange is that the results
> of the different attempts often different.

For what it's worth, I've done 3 installs of QuickDraw GX beta 3 so far,
from the March developer CD. The two on 68040 machines (a Centris 650 and an
840AV) worked perfectly. I've been through the _entire_ SlideMaster demo on
both machines without a single crash! And several parts were noticeably faster
than with beta 2.

I installed the PPC version on a PowerMac 6100/60AV. That one mostly works,
but I got one crash in SlideMaster, and printers don't seem to appear reliably
in the Chooser.

One definite problem is that I can't print to a LaserJet 4ML with the
LaserWriter GX driver. But then, it's not the first problem I've had with an
HP PostScript printer...

By the way, here's a small puzzle that might entertain some. After updating
to the b3 interfaces and recompiling my code, none of it would work. It took
me two days to figure out what the problem was. Here's an example of what I
was doing wrong: can you spot the mistake?

    PROCEDURE GXNewShape
      (
    aType : gxShapeType
      ) : gxShape;

    CODE
        0709EH,        (* moveq.l #$9E, d0 *)
        0A832H,        (* _Skia *)
        0588FH,        (* addq.l #4, sp *)
        02E80H;        (* move.l d0, (sp) *)

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

>From [e-mail] (Tim Hammett)
Date: 22 Mar 1994 23:52:57 GMT
Organization: University of Auckland

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>By the way, here's a small puzzle that might entertain some. After updating
>to the b3 interfaces and recompiling my code, none of it would work. It took
>me two days to figure out what the problem was. Here's an example of what I
>was doing wrong: can you spot the mistake?
>
>    PROCEDURE GXNewShape
>      (
>    aType : gxShapeType
>      ) : gxShape;
>
>    CODE
>        0709EH,        (* moveq.l #$9E, d0 *)
>        0A832H,        (* _Skia *)
>        0588FH,        (* addq.l #4, sp *)
>        02E80H;        (* move.l d0, (sp) *)

I'll take a guess (at the risk of making myself look like an idiot).

I assume that $9e is the routine selector which you pass to the
_Skia trap to tell it you want to do a GXNewShape(). My guess
is that moveq sign extends the $9e (since it's negative when
considered as a byte), so while you thought you were passing
$0000009e in d0, you were actually passing $ffffff9e.

KON: Nasty.

BAL: Yup.

--
Tim Hammett, School of Biological Sciences, Auckland University, New Zealand.
[e-mail]   Phone: [phone] x8365    FAX: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Tue, 22 Mar 1994 23:08:28 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>    PROCEDURE GXNewShape
>      (
>    aType : gxShapeType
>      ) : gxShape;

>    CODE
>        0709EH,        (* moveq.l #$9E, d0 *)
>        0A832H,        (* _Skia *)
>        0588FH,        (* addq.l #4, sp *)
>        02E80H;        (* move.l d0, (sp) *)

How come your compiler didn't barf at having a *procedure* that returns
a result? Also, wouldn't a moveq.l sign-extend 9E before stuffing it into
D0?

-Ivan
- -
Ivan Cavero Belaunde ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.


+++++++++++++++++++++++++++

>From Stephan Bublava <[e-mail]>
Date: 23 Mar 1994 08:34:32 GMT
Organization: Vienna University of Technology

In article <[e-mail]> Ivan M CaveroBelaunde,
[e-mail] writes:

>How come your compiler didn't barf at having a *procedure*
>that returns a result?

Because it is Modula-2 and not Pascal.

--
Stephan Bublava
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Glenn Andreas)
Date: Wed, 23 Mar 1994 14:57:43 GMT
Organization: SCTC

[e-mail] (Stephen Marshall) writes:

>Hi,

>I have just tried to run this off the March Developers CD and got a finder
>error 41 (could not load finder?). Has anyone else encountered this
>problem? Happens on a 660av and an LC475 with a new install of System 7.1.

Well, after having the same problem, I finally found a way around it (see
my previous post for more symptoms).

I copied the installer folder onto my hard disk (takes 6.2 megs).  I then
took the Installer 4.0GM from the April dev CD (arived yesterday).  Modified
the installer script in ResEdit to say version 4.0 instead of 4.0b1.  Launched
the installer and proceeded as normal.

So it appears that the problem was not the CD (though I did try cleaning it)
but rather flaky behavior with the beta installer.

Glenn

+++++++++++++++++++++++++++

>From [e-mail] (Stephen Marshall)
Date: 24 Mar 1994 01:36:41 GMT
Organization: Victoria University of Wellington


> [e-mail] (Stephen Marshall) writes:
>
> >Hi,
>
> >I have just tried to run this off the March Developers CD and got a finder
> >error 41 (could not load finder?). Has anyone else encountered this
> >problem? Happens on a 660av and an LC475 with a new install of System 7.1.
>
> >Stephen Marshall

In article <[e-mail]>, [e-mail] (Glenn
Andreas) wrote:
>
What is happening is that the QuickDraw GX file is compressed on the CD and
when the installer goes to expand it, something goes wrong, which results
in resource fork being hosed.  The finder goes to open the resource fork,
and fails, thus the message.
>

Lawrence D'Olivero wrote:
>
For what it's worth, I've done 3 installs of QuickDraw GX beta 3 so far,
from the March developer CD.
>

And someone else suggested I clean the CD.

Well, despite Lawrence's (and presumably many other's) happy experiences I
have not been able to install the software. When I try to open the
Quickdraw GX extension with ResEdit I am informed that the file is corrupt
and should be replaced with a backup. This is with a clean CD (well
polished 8-), and also with trying to install from a hard disk rather than
the CD.

I can't help wondering if a subset of the CDs have been incorrectly
produced or damaged in some fashion (???). I guess I will have to wait for
the next release of the software 8-(

Stephen
--
Macintosh Consultant                              [e-mail]
Victoria University of Wellington
New Zealand

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 24 Mar 94 17:00:06 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Ivan M CaveroBelaunde) writes:
> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>>    PROCEDURE GXNewShape
>>      (
>>    aType : gxShapeType
>>      ) : gxShape;
>
>>    CODE
>>        0709EH,        (* moveq.l #$9E, d0 *)
>>        0A832H,        (* _Skia *)
>>        0588FH,        (* addq.l #4, sp *)
>>        02E80H;        (* move.l d0, (sp) *)
>
> How come your compiler didn't barf at having a *procedure* that returns
> a result?

Hint: the language doesn't have a "FUNCTION" keyword.

> Also, wouldn't a moveq.l sign-extend 9E before stuffing it into
> D0?

Give the man a cigar!

Lawrence
(only using moveq's for selectors up to 7F now.)

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Wed, 30 Mar 1994 01:53:07 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Stephen Marshall) wrote:

> Well, despite Lawrence's (and presumably many other's) happy experiences I
> have not been able to install the software. When I try to open the
> Quickdraw GX extension with ResEdit I am informed that the file is corrupt
> and should be replaced with a backup. This is with a clean CD (well
> polished 8-), and also with trying to install from a hard disk rather than
> the CD.

ResEdit will normally offer to repair this, and the resulting file
should be usable.

> I can't help wondering if a subset of the CDs have been incorrectly
> produced or damaged in some fashion (???). I guess I will have to wait for
> the next release of the software 8-(

Should be out soon -- but what is on the disk should install with
the exception of the "repair" mentioned above.

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

---------------------------

End of C.S.M.P. Digest
**********************